1. Technical Field
The present invention relates to a computer networking system, and deals more particularly with a method, system, and computer-readable code for delegating authentication and authority from a client to a server in order that the server can establish a secure connection to a back-end application on behalf of the client.
2. Related Art
As the amount of commerce continues to increase over networks, such as the Internet, security becomes a much larger issue. Unfortunately, the protocols underlying the Internet such as TCP/IP (Transmission Control Protocol/Internet Protocol), were not designed to provide secure data transmission. The Internet was originally designed with the academic and scientific communities in mind, and it was assumed that the users of the network would be working in non-adversarial, cooperative manners. As the Internet began to expand into a public network, usage outside these communities was relatively limited, with most of the new users located in large corporations. These corporations had the computing facilities to protect their user""s data with various security procedures, such as firewalls, that did not require security to be built into the Internet itself. In the past several years, however, Internet usage has skyrocketed. Millions of people now use the Internet and the Web on a regular basis. (Hereinafter, the terms xe2x80x9cInternetxe2x80x9d and xe2x80x9cWebxe2x80x9d are used synonymously unless otherwise indicated.) These users perform a wide variety of tasks, from exchanging electronic mail messages to searching for information to performing business transactions. These users may be accessing the Internet from home, from their cellular phone, or from a number of other environments where security procedures are not commonly available.
To support the growth of business on the Internet, often referred to as xe2x80x9celectronic commercexe2x80x9d or simply xe2x80x9ce-commerce,xe2x80x9d easily-accessible and inexpensive security procedures had to be developed. A first commonly used security measure involves a Public Key Infrastructure (hereinafter xe2x80x9cPKIxe2x80x9d). PKI utilizes certificates as a basis for a security infrastructure. Certificates utilize public keys and third party verification entities to allow servers to decode client transmissions and authenticate the clients identity. In operation, a first node in a network can encrypt a message with their own private key. The message can be read by a second node with the first node""s public key. A public key can only be used to decrypt messages created by the private key and cannot be used to encrypt messages. Thus, the first node is free to distribute their public key. One way in which public keys are distributed is by including them in certificates. There are a number of standards for certificates including the X0.509 standard, which defines a standard format for certificates. X0.509 is an ITU Recommendation and International Standard that defines a framework for providing authentication. (See xe2x80x9cITU Recommendation X0.509 (1997) Information Technologyxe2x80x94Open Systems Interconnectionxe2x80x94The Directory: Authentication Frameworkxe2x80x9d, hereinafter xe2x80x9cDirectory specificationxe2x80x9d, dated 11/93. This information is also published in International Standard ISDO/IEC 9594-8 (1995).) A certificate format is defined in this standard. Certificates created according to this international standard, in the defined format, are referred to as xe2x80x9cX0.509 certificatesxe2x80x9d.
In addition, Secure Sockets Layer, or xe2x80x9cSSLxe2x80x9d is also utilized to set up encrypted communication links and make use of certificates. SSL is commonly used with applications that send and receive data using the HyperText Transfer Protocol (xe2x80x9cHTTPxe2x80x9d). HTTP is the protocol most commonly used for accessing that portion of the Internet referred to as the Web. When HTTP is used with SSL to provide secure communications, the combination is referred to as xe2x80x9cHTTPS.xe2x80x9d Non-commercial Internet traffic can also benefit from the security SSL provides. SSL has been proposed for use with data transfer protocols other than HTTP, such as Simple Mail Transfer Protocol (xe2x80x9cSMTPxe2x80x9d) and Network News Transfer Protocol (xe2x80x9cNNTPxe2x80x9d).
SSL is a networking protocol developed by Netscape Communications Corp. and RSA Data Security, Inc. to enable secure network communications in a non-secure environment, where it operates as a protocol layer above the TCP/IP layers. The application code then resides above SSL in the networking protocol stack. After an application (such as a browser) creates data to be sent to a peer in the network, the data is passed to the SSL layer where various security procedures are performed on it, and the SSL layer then passes the transformed data on to the TCP layer. On the receiver""s side of the connection, after the TCP layer receives incoming data, the data is passed upward to the SSL layer where procedures are performed to restore the data to its original form, and that restored data is then passed to the receiving application. The most recent version of SSL is described in detail in xe2x80x9cthe SSL Protocol, Version 3.0,xe2x80x9d dated Nov. 18, 1996 and available on the World Wide Web (xe2x80x9cWebxe2x80x9d) at http ://home.netscape.com/eng/ss 13/draft302.txt (hereinafter, xe2x80x9cSSL specificationxe2x80x9d).
These security features are very powerful, and provide a high degree of protection for Internet users. However, both PKI and SSL were designed as two-party protocols, to be used in a simple client/server environment. The SSL protocol allows a client to request a secure communication session by sending a message to a server application. The server then responds, and a sequence of messages are exchanged in a handshaking protocol where the various security-related parameters are negotiated. The encryption algorithms to be used for message privacy and data integrity are agreed upon, and both the client and server may authenticate each other""s identity. Authentication is performed during the handshake by exchanging digital certificates. The server sends its certificate to the client, enabling the client to authenticate the server""s identity. The server then requests the client""s certificate, which the client sends in order that the server can also authenticate the client""s identify. If the authentication results are acceptable, the parties complete the handshake, and begin to exchange encrypted application data over the secure session they have established.
While the aforementioned security measures have proved to be useful for a two-party protocol, the traditional client-server model for network computing is being extended in the web environment to what is referred to as a xe2x80x9cmulti-tier architecture.xe2x80x9d This architecture may be characterized as a chain of nodes (e.g., a client and multiple servers) wherein a middle-tier or intermediate server may need to contact an end-tier server on behalf of the client. In such a case, the middle-tier server is said to be acting as a delegate of the client, and the process is generally referred to as delegation. In general, there is no limitation on the number of nodes involved in a delegation process. Thus, a first-tier server in contact with a client may be required to act as a delegate of the client by contacting a second-tier server on the client""s behalf, and the second-tier server may be required to contact a third-tier server on behalf of either/both the second-tier server or the client.
This multi-tiered architecture recognizes the fact that many client requests do not simply require the location and return of static data by the first server, but require an application program to perform processing of the client""s request in order to dynamically create and format the data to be returned. For example, during a commercial transaction between a client and a first server, the first server may need to contact a second server to collect financial information or perform a financial transaction on behalf of the client. In turn, the second server may need to collect a credit history on behalf of the client from a third server, etc. During each such new request in such a chain, it is often imperative that the server fulfilling the request be able to verify that the action is being done with the permission of the client, and/or a previous server in the chain. For example, before a second server (e.g., a bank) debits a client""s account based upon a request from a first server (e.g., a commercial web site), the bank must be certain that the client gave permission to do this. Thus, the second server must have some reliable mechanism for verifying a delegated action.
Unfortunately, security protocols, such as those provided by SSL, are strictly two-party protocols, i.e., their use is limited to establishing a secure session between the client and a first or middle-tier server. Accordingly, there are no current methods for extending these secure sessions into a multi-tiered environment. The client authentication process within SSL is designed such that the client digitally signs data that it derives from the middle-tier server""s certificate during the handshaking protocol. This digital signature requires the client to use its private key for encryption, and to send the resulting signature back to the middle-tier server along with the client""s certificate. The client""s private key must never leave the client machine, or it would no longer meet the requirements for a private key. Thus, the middle-tier server cannot create a digital signature on behalf of the client, because the middle-tier server cannot learn the client""s private key.
U.S. Pat. No. 5,224,163, entitled METHOD FOR DELEGATING AUTHORIZATION FROM ONE ENTITY TO ANOTHER THROUGH THE USE OF SESSION ENCRYPTION KEYS, issued to Gasser et al. on Jun. 29, 1993, which describes many of the protocols described herein, utilizes a set of point to point certificates sent in sequences. However, the ""163 patent does not provide a single signed data structure that can be examined by each server in a chain of servers for delegation purposes. Accordingly, a need exists for a technique for providing security in a multi-tier network environment such that the client""s identity can be certified by any server fulfilling requests for the client. Each of the above references is hereby incorporated by reference.
The present invention overcomes the above-mentioned problems by providing a network system that includes a verification system, the network system comprising: a plurality of sequential nodes 1 . . . M, wherein each node n within the plurality of sequential nodes includes a system for securely communicating with an nth+1 node on behalf of any earlier node; a verification program stored on a computer readable medium, and executable by the nth+1 node to verify any of the earlier nodes by examining a certification data structure (CDS) built by the nthxe2x88x921 node, wherein the verification program comprises: a mechanism for opening the certification data structure created by the nthxe2x88x921 node, a mechanism for extracting a public key of the nthxe2x88x921 node from the certification data structure, and a mechanism for verifying a signature of the certification data structure.
The certification data structure created by an nthxe2x88x921 node may comprise: a first field containing a certificate of the nthxe2x88x921 node; a second field containing a certificate of the nth node; a third field containing an expiration time stamp; a fourth field containing a maximum node depth; a fifth field containing the certificate data structure created by the nthxe2x88x922 node, and a sixth field containing a digital signature of the first, second, third, fourth, and fifth fields encrypted by a private key of the nthxe2x88x921 node.
Thus, each certification data structure comprises a nested set of previous certification data structures. In this manner, a single data structure format can be utilized by any server for delegation purposes. Accordingly, the verification program need only open a single data structure to verify each previous node in a chain delegating nodes. (Note that the certification data structure created by the first node need not include the fifth field, since there exist no prior nodes.)